home *** CD-ROM | disk | FTP | other *** search
/ Gigarom 1 / Gigarom Macintosh Archives (Quantum Leap)(CDRM1080320)(1993).iso / FILES / HYP / H-I / HyperHackers.cpt / Hyper-Hackers Queue 1.0 / card_19956.txt < prev    next >
Text File  |  1989-02-26  |  3KB  |  60 lines
  1. -- card: 19956 from stack: in.0
  2. -- bmap block id: 0
  3. -- flags: 0000
  4. -- background id: 3797
  5. -- name: 
  6.  
  7.  
  8. -- part contents for background part 1
  9. ----- text -----
  10.  
  11. From: mitch@well.UUCP (Mitchell Waite)
  12.  
  13. Date: 28 Feb 88 20:31:16 GMT
  14.  
  15. It should be mentioned that the message posted in this digest several weeks
  16. ago regarding simultaneous field scrolling rather misses the point.  The
  17. statement that was made (I forget the name of the author) was that fields
  18. could be made to scroll together merely by a script that says "set the
  19. scroll of field A to the scroll of field B", presumably running in a
  20. handler for "idle."
  21.   This solution solves only the simplest and crudest needs of simultaneous
  22. scrolling.  First, the fields do not really scroll together; they scroll
  23. in sequence.  The first field moves, then, only after a mouseup, will the
  24. second field catch up.  If the second field is an index field, this staggered
  25. behavior prevents one from knowing how far he has scrolled until it is too
  26. late.
  27.  
  28. I am sorry Mr. Belsley did not research HyperTalk a little deeper, because we
  29. did and found that this problem can be overcome by setting lockscreen to true
  30. during the scroll. That way both fields (or all eight if you use that many) will
  31. move in sync. This scroll will not be as fast as a pure HyperTalk scroll box
  32. scroll, but in some applications, such as ours, which displays a glossary, it is
  33. fine. We scroll three lines at a time to make the box seem faster also.
  34.  
  35.    Second, this solution does not allow for selecting in the field beyond
  36. the portion of the field showing in the window.  If one attempts to select
  37. beyond the scroll, the moment the mouse is let up, the second window
  38. "catches us," and, in so doing, removes the selection from the first window.
  39.  
  40. I assume the complaint is the field won't scroll when its being edited, and this
  41. seems right, but I never said it's contents were editable. Rather we are using
  42. it for read only. What Mr. Belsley wants I think could be simulated in HyperTalk
  43. with a little creativity in our script.
  44.  
  45.    Third, the same phenomenon besets the  positioning of the insertion point
  46. since the insertion point will be "removed" from the first window after
  47. contol is given to the second window for its scroll to catch up.
  48.  
  49. See above. May be able to work around.
  50.  
  51. If anyone is interested in seeing my dueling scroll fields stack (yes dueling is
  52. a play on words) it can be found in DL10 of apphype in Compuserve as the file
  53. DUELSC.SIT. If enough people on usenet want to look it over I will be happy to
  54. upload to the binaries. Its 30K in StuffIt/binhex format.
  55.  
  56.  
  57.  
  58. -- part contents for background part 45
  59. ----- text -----
  60. Dual Scrolling Fields Possible